home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-tuba-clnp-02.txt
< prev
next >
Wrap
Text File
|
1993-03-03
|
45KB
|
1,368 lines
IETF Page 1
January 6, 1993 CLNP for TUBA Internet Draft
Use of ISO CLNP in TUBA Environments
David M. Piscitello
Bellcore
dave@sabre.bellcore.com
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its
Areas, and its Working Groups. Note that other groups may also
distribute working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use
Internet Drafts as reference material or to cite them other than
as a "working draft" or "work in progress."
Please check the Internet Draft abstract listing contained in the
IETF Shadow Directories (cd internet-drafts) to learn the current
status of this or any other Internet Draft.
This Internet-Draft specifies a profile of the ISO 8473
Connectionless-mode Network Layer Protocol (CLNP, [1]) for use in
conjunction with RFC 1347, TCP/UDP over Bigger Addresses (TUBA,
[2]). This draft document will be submitted to the RFC editor as
a protocol specification. Distribution of this memo is unlimited.
Please send comments to dave@eve.bellcore.com.
Abstract
This document describes the use of CLNP to provide the lower-
level service expected by Transmission Control Protocol (TCP,
[3]) and User Datagram Protocol (UDP, [4]). CLNP provides
essentially the same datagram service as Internet Protocol (IP,
[5]), but offers a means of conveying bigger network addresses
(with additional structure, to aid routing).
While the protocols offer nearly the same services, IP and CLNP
are not identical. This document describes a means of preserving
the semantics of IP information that is absent from CLNP while
preserving consistency between the use of CLNP in Internet and
OSI environments. This maximizes the use of already-deployed CLNP
implementations.
Acknowledgments
IETF Page 2
Internet Draft CLNP for TUBA January 6, 1993
Many thanks to Ross Callon of Digital Equipment, Brian Carpenter
of CERN, and Dave Katz of Cisco Systems for their assistance in
composing this text.
Conventions
The following language conventions are used in the items of
specification in this document:
o+ Must, Shall, or Mandatory -- the item is an absolute
requirement of the specification.
o+ Should or Recommended -- the item should generally be
followed for all but exceptional circumstances.
o+ May or Optional -- the item is truly optional and may be
followed or ignored according to the needs of the
implementor.
1. Terminology
To the extent possible, this document is written in the language
of the Internet. For example, packet is used rather than
"protocol data unit", and "fragment" is used rather than
"segment". There are some terms that carry over from OSI; these
are, for the most part, used so that cross-reference between this
document and RFC994 or ISO 8473 is not entirely painful. OSI
acronyms are for the most part avoided.
2. Introduction
The goal of this specification is to allow compatible and
interoperable implementations to encapsulate TCP and UDP packets
in CLNP data units. It is assumed that readers are familiar with
RFC 791 and, to a lesser extent, RFC 994 and ISO 8473. This
document is compatible with (although more restrictive than) ISO
8473; specifically, the order, semantics, and processing of CLNP
header fields is consistent between this and ISO 8473. However,
it is intended that this document be able to stand on its own
without reference to ISO 8473, at least with respect to
implementing CLNP to provide the lower-level service expected by
TCP and UDP.
[Editor's Note: RFC 994 contains the Draft International Standard
version of ISO CLNP [6], in ASCII text. This is not the final
version of the ISO protocol specification; however, it should
provide sufficient background for the purpose of understanding
the relationship of CLNP to IP, and the means whereby IP
information is to be encoded in CLNP header fields. Postscript
versions of ISO CLNP and associated routing protocols are
IETF Page 3
January 6, 1993 CLNP for TUBA Internet Draft
available via anonymous FTP from merit.edu, and may be found in
the directory /pub/iso.]
3. Overview of CLNP
ISO CLNP is a datagram network protocol. It provides
fundamentally the same underlying service to a transport layer as
IP. CLNP provides essentially the same maximum datagram size, and
for those circumstances where datagrams may need to traverse a
network whose maximum packet size is smaller than the size of the
datagram, CLNP provides mechanisms for fragmentation (data unit
identification, fragment/total length and offset). Like IP, a
checksum computed on the CLNP header provides a verification that
the information used in processing the CLNP datagram has been
transmitted correctly, and a lifetime control mechanism ("Time to
Live") imposes a limit on the amount of time a datagram is
allowed to remain in the internet system. As is the case in IP, a
set of options provides control functions needed or useful in
some situations but unnecessary for the most common
communications.
Table 1 provides a high-level comparison of CLNP to IP:
Function | ISO CLNP | DOD IP
------------------------|-----------------------|-----------------------
Version Identifier | 1 octet | 4 bits
Header Length | indicated in octets | in 32-bit words
Total Length | 16 bits, in octets | 16 bits, in octets
Data Unit Identifier | 16 bits | 16 bits
Flags | Fragmentation allowed,| Don't Fragment,
| More Fragments | More Fragments,
| Suppress Error Reports| <not defined>
Fragment offset | 16 bits, in octets | 13 bits, 8-octet units
Lifetime (Time to live) | 500 msec units | 1 sec units
Higher Layer Protocol | Selector in address | PROTOcol (assigned #)
Header Checksum | 16-bit (Fletcher) | 16-bit
Addressing | Variable length | 32-bit fixed
Options | Security | Security
| Priority | Precedence bits in TOS
| Complete Source Route | Strict Source Route
| Quality of Service | Type of Service
| Partial Source Route | Loose Source Route
| Record Route | Record Route
| Padding | Padding
| <defined herein> | Timestamp
Table 1. Comparison of IP to CLNP
IETF Page 4
Internet Draft CLNP for TUBA January 6, 1993
Note that the encoding of options differs between the two
protocols, as do the means of higher level protocol
identification. Note also that CLNP and IP differ in the way
header and fragment lengths are represented, and that the
granularity of lifetime control (time-to-live) is finer in CLNP.
Some of these differences are not considered "issues", as CLNP
provides flexibility in the way that certain options may be
specified and encoded (this will facilitate the use and encoding
of certain IP options without change in syntax); others, e.g.,
higher level protocol identification and timestamp, must be
accommodated in a transparent manner in this profile for correct
operation of TCP and UDP, and continued interoperability with OSI
implementations. Section 4 describes how header fields of CLNP
must be populated to satisfy the needs of TCP and UDP.
Errors detected during the processing of a CLNP datagram may be
reported using CLNP Error Reports. Implementations of CLNP for
TUBA environments must be capable of processing Error Reports
(this is consistent with the 1992 version of the ISO 8473
standard). Control messages (e.g., echo request/reply and
redirect) are similarly handled in CLNP, i.e., identified as
separate network layer packet types. The relationship between
CLNP Error and Control messages and Internet Control Message
Protocol (ICMP, [7]), and issues relating to the handling of
these messages is described in Section 5.
The composition and processing of a TCP pseudo-header when CLNP
is used to provide the lower-level service expected by TCP and
UDP is described in Section 6.
4. Proposed Internet Header using CLNP
A summary of the contents of the CLNP header, as it is proposed
for use in TUBA environments, is illustrated in Figure 4-1:
IETF Page 5
January 6, 1993 CLNP for TUBA Internet Draft
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........Data Link Header........ | NLP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Header Length | Version | Lifetime (TTL)|Flags| Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest Addr Len | Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PROTO field | Src Addr Len | Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address | Reserved | Data Unit... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...Identifier | Fragment Offset |Total Length.. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... of Packet | Options... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: :
| Options (see Table 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that each tick mark represents one bit position.
Figure 4-1. CLNP for TUBA
Note 1: For illustrative purposes, Figure 4-1 depicts Destination and
Source Addresses having a length of 19 octets, including the
PROTO/reserved field. In general, addresses can be variable
length, up to a maximu of 20 octets, including the
PROTO/reserved field.
IETF Page 6
Internet Draft CLNP for TUBA January 6, 1993
Note 2: Due to differences in link layer protocols, it is not possible
to ensure that the packet starts on an even alignment. Note,
however, that many link level protocols over which CLNP is operated
happen to use a odd length link (e.g., 802.2). (As profiled in
Figure 4-1, the rest of the CLNP packet is even-aligned.)
The encoding of CLNP fields for use in TUBA environments is as
follows.
4.1 Network Layer Protocol Identification (NLP ID)
This one-octet field identifies this as the ISO 8473 protocol; it
must set to binary 1000 0001.
4.2 Header Length Indication (Header Length)
Header Length is the length of the CLNP header in octets, and
thus points to the beginning of the data. The value 255 is
reserved. The header length is the same for all fragments of the
same (original) CLNP packet.
[Note: General purpose CLNP implementations must be willing to
accept addresses of variable length up to 20 octets. In
particular, implementations that are expected to support both
GOSIP and RFC 1237 [13] style addresses in addition to "TUBA"
addresses [8]. must be capable of dealing with 20-octet
addresses.]
4.3 Version
This one-octet field identifies the version of the protocol; it
must be set to a binary value 0000 0001.
4.4 Lifetime (TTL)
Like the TTL field of IP, this field indicates the maximum time
the datagram is allowed to remain in the internet system. If
this field contains the value zero, then the datagram must be
destroyed. This field is modified in internet header processing.
The time is measured in units of 500 milliseconds, but since
every module that processes a datagram must decrease the TTL by
at least one even if it process the datagram in less than 500
millisecond, the TTL must be thought of only as an upper bound on
the time a datagram may exist. The intention is to cause
undeliverable datagrams to be discarded, and to bound the maximum
CLNP datagram lifetime. [Like IP, the colloquial usage of TTL in
CLNP is as a coarse hop-count.]
IETF Page 7
January 6, 1993 CLNP for TUBA Internet Draft
4.5 Flags
Three flags are defined. These occupy bits 0, 1, and 2 of the
Flags/Type octet:
0 1 2
+---+---+---+
| F | M | E |
| P | F | R |
+---+---+---+
The Fragmentation Permitted (FP) flag, when set to a value of one
(1), is semantically equivalent to the "may fragment" value of
the Don't Fragment field of IP; similarly, when set to zero (0),
the Fragmentation Permitted flag is semantically equivalent to
the "Don't Fragment" value of the Don't Fragment Flag of IP.
[Editor's Note: If the Fragmentation Permitted field is set to
the value O, then the Data Unit Identifier, Fragment Offset, and
Total Length fields are not present. This denotes a single
fragment datagram. In such datagrams, the Fragment Length field
contains the total length of the datagram.]
The More Fragments flag of CLNP is semantically and syntactically
the same as the More Fragments flag of IP; a value of one (1)
indicates that more segments/fragments are forthcoming; a value
of zero (0) indicates that the last octet of the original packet
is present in this segment.
The Error Report (ER) flag is used to suppress the generation of
an error message by a host/router that detects an error during
the processing of a CLNP datagram; a value of one (1) indicates
that the host that originated this datagram thinks error reports
are useful, and would dearly love to receive one if a host/router
finds it necessary to discard its datagram(s).
4.6 Type field
The type field distinguishes data CLNP packets from Error Reports
from Echo packets. The following values of the type field apply:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| flags | 1 | 1 | 1 | 0 | 0 | => Encoding of Type = data packet
+---+---+---+---+---+---+---+---+
| flags | 0 | 0 | 0 | 0 | 1 | => Encoding of Type = error report
+---+---+---+---+---+---+---+---+
| flags | 1 | 1 | 1 | 1 | 0 | => Encoding of Type = echo request
+---+---+---+---+---+---+---+---+
| flags | 1 | 1 | 1 | 1 | 1 | => Encoding of Type = echo reply
+---+---+---+---+---+---+---+---+
IETF Page 8
Internet Draft CLNP for TUBA January 6, 1993
Error Report packets are described in Section 5.
Echo and its use is described in RFC 1139 [14].
4.7 Fragment Length
Like the Total Length of the IP header, the Fragment length field
contains the length in octets of the fragment (i.e., this
datagram) including both header and data. [Note: CLNP also has a
Total Length field, that contains the length of the original
datagram; i.e., the sum of the length of the CLNP header plus the
length of the data submitted by the higher level protocol, e.g.,
TCP or UDP).
4.8 Checksum
A checksum is computed on the header only. It is verified at each
host/router that processes the packet; if header fields are
changed during processing (e.g., the Lifetime), the checksum is
modified. If the checksum is not used, this field must be coded
with a value of zero (0). See Appendix A for algorithms used in
the computation and adjustment of the checksum.
4.9 Destination Address Length Indicator ()
This field indicates the length, in octets, of the Destination
Address.
4.10 Destination Address
The format of the address encoded in this field is described in a
companion addressing document, see [8].
For compatibility and interoperability with OSI use of CLNP, the
initial octet of the Destination Address is assumed to be an
Authority and Format Indicator, as defined in ISO 8348 [7]. A
destination address may be between 8 and 20 octets long
(inclusive). The final octet of the destination address must
always contain the value of the PROTO field, as defined in IP.
The 8-bit PROTO field indicates the next level protocol used in
the data portion of the CLNP datagram. The values for various
protocols are specified in "Assigned Numbers" [9]. For the PROTO
field, the value of zero (0) is reserved.
4.11 Source Address Length Indicator ()
This field indicates the length, in octets, of the Source
Address.
IETF Page 9
January 6, 1993 CLNP for TUBA Internet Draft
4.12 Source Address
The format of the address encoded in this field is described in a
companion addressing document, see [8].
For compatibility and interoperability with OSI use of CLNP, the
initial octet of the Destination Address is assumed to be an
Authority and Format Indicator, as defined in ISO 8348 [7]. A
destination address may be between 8 and 20 octets long
(inclusive). The final octet of the source address is reserved.
It may be set to the protocol field value on transmission, and
shall be ignored on reception (the value of zero must not be
used).
4.13 Data Unit Identifier
Like the Identification field of IP, this 16-bit field is used to
distinguish segments of the same (original) packet for the
purposes of reassembly.
4.14 Fragment Offset
Like the Fragment Offset of IP, this 16-bit is used to identify
the relative octet position of the data in this fragment with
respect to the start of the data submitted to CLNP; i.e., it
indicates where in the original datagram this fragment belongs.
4.15 Options
All CLNP options are "triplets" of the form <parameter code>,
<parameter lenth>, and <parameter value>. Both the parameter
code and length fields are always one octet long; the length
parameter value, in octets, is indicated in the parameter length
field. The following options are defined for CLNP for TUBA.
4.15.1 _S_e_c_u_r_i_t_y
The value of the parameter code field is binary 1100 0101. The
length field must be set to the length of a Basic (and Extended)
Security IP option(s) as identified in RFC1108 [10], plus 1.
Octet 1 of the security parameter value field -- the CLNP
Security Format Code -- is set to a binary value 0100 0000,
indicating that the remaining octets of the security field
contain either the Basic or Basic and Extended Security options
as identified in RFC 1108 [10]. This encoding points to the
administration of the source address (e.g., ISOC) as the
administration of the security option; it is thus distinguished
from the globally unique format whose definition is reserved for
OSI use. Implementations must examine the PROTO field in the
source address; if the value of PROTO indicates the CLNP client
is TCP or UDP, the security option described in RFC1108 is used.
IETF Page 10
Internet Draft CLNP for TUBA January 6, 1993
The formats of the Security option, encoded as a CLNP option, is
as follows. The CLNP option will be used to convey the Basic and
Extended Security options as sub-options; i.e., the exact
encoding of the Basic/Extended Security IP Option is carried in a
single CLNP Security Option, with the length of the CLNP Security
option reflecting the sum of the lengths of the Basic and
Extended Security IP Option.
+--------+--------+--------+--------+--------+------//-----+---
|11000100|XXXXXXXX|01000000|10000010|YYYYYYYY| | ...
+--------+--------+--------+--------+--------+------//-----+------
CLNP CLNP CLNP BASIC BASIC BASIC
OPTION OPTION FORMAT SECURITY OPTION OPTION
TYPE LENGTH CODE TYPE LENGTH VALUE
(197) (130)
---+------------+------------+----//-------+
... | 10000101 | 000LLLLL | |
-----+------------+------------+----//-------+
EXTENDED EXTENDED EXTENDED OPTION
OPTION OPTION VALUE
TYPE (133) LENGTH
The syntax, semantics and processing of the Basic and Extended
IP Security Options are defined in RFC1108.
4.15.2 _T_y_p_e__o_f__S_e_r_v_i_c_e
The value of the parameter code field must be set to a value of
binary 1100 0011 (the CLNP Quality of Service Option Code point).
The length field must be set to the length of the type of service
field as identified in RFC1349, Type of Service in the Internet
Protocol Suite [11], plus 1 (i.e., the value is 2). Octet 1 of
the type of service parameter field is set to a binary value 0100
0000, indicating that the remaining octet of the Type Of Service
field is to be encoded as described in RFC1349. This encoding
points to the administration of the source address (e.g., ISOC)
as the administration of the CLNP QOS option; it is thus
distinguished from the globally unique QOS format whose
definition is reserved for OSI use. Implementations must examine
the PROTO field in the source address; if the value of PROTO
indicates the CLNP client is TCP or UDP, the TOS described in
RFC1349 is used.
IETF Page 11
January 6, 1993 CLNP for TUBA Internet Draft
+-----------+----------+----------+----------+
| 1100 0011 | 00000010 | 01000000 | PPPTTTT0 |
+-----------+----------+----------+----------+
CLNP QOS OPTION QOS FORMAT IP TOS
TYPE (195) LENGTH CODE OCTET
The Type of Service octet consists of three fields:
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | TOS | MBZ |
+-----+-----+-----+-----+-----+-----+-----+-----+
The first field, labeled "PRECEDENCE" above, is intended to
denote the importance or priority of the datagram. The second
field, labeled "TOS" above, denotes how the network should make
tradeoffs between throughput, delay, reliability, and cost. The
last field must be zero ("MBZ").
The processing of the type of service option is defined in
RFC1349. The rules for applying TOS in Error and Report messages
should correspond to those applied to the corresponding ICMP
messages; i.e., error messages must always be sent with the
default TOS; request messages may have any correct TOS value, and
replies must be sent with the same value in the TOS field as was
used in the corresponding request message.
[Editor's Note: It has been suggested that the IP precedence map
directly into a CLNP option, Priority. The feature will be
provided irrespective of whether precedence is encoded in the TOS
or Priority option.]
4.15.3 _P_a_d_d_i_n_g
The padding field is used to lengthen the packet header to a
convenient size. The parameter code field must be set to a value
of binary 1100 1100. The value of the parameter length field is
variable. The parameter value may contain any value.
+----------+----------+-----------+
| 11001100 | LLLLLLLL | VVVV VVVV |
+----------+----------+-----------+
4.15.4 _S_o_u_r_c_e__R_o_u_t_i_n_g
Like the strict source route option of IP, the Complete Source
Route option of CLNP is used to specify the exact and entire
route an internet datagram must take. Similarly, the Partial
Source Route option of CLNP provides the equivalent of the loose
source route option of IP; i.e., a means for the source of an
IETF Page 12
Internet Draft CLNP for TUBA January 6, 1993
internet datagram to supply (some) routing information to be used
by gateways in forwarding the internet datagram towards its
destination.
The parameter code for Source Routing is binary 1100 1000. The
length of the source routing parameter value is variable.
The first octet of the parameter value is a type code, indicating
Complete Source Routing (binary 0000 0001) or partial source
routing (binary 0000 0000). The second octet identifies the
offset of the next network entity title to be processed in the
list, relative to the start of the parameter (i.e., a value of 3
is used to identify the first address in the list). The third
octet begins the list of network entity titles.
4.15.5 _R_e_c_o_r_d__R_o_u_t_e
Like the IP record route option, the Record route option of CLNP
is used to trace the route a CLNP datagram takes.
The parameter code for Record Route is binary 1100 1011. The
length of the record route parameter value is variable.
The first octet of the parameter value is a type code, indicating
Complete Source Route (0000 0001) Partial Recording of Route
(0000 0000). The second octet identifies the offset where the
next network entity title may be recorded (i.e., the end of the
current list), relative to the start of the parameter (i.e., a
value of 3 is used to identify the initial recording position).
If recording of route has been terminated (I'll be back...), this
octet has a value 255. The third octet begins the list of network
entity titles.
4.15.6 _T_i_m_e_s_t_a_m_p
[Editor's Note: There is no timestamp option in CLNP. We propose
to define the option and submit it to ISO; temporarily, we will
be most presumptuous and "borrow" a code point from the many that
are reserved.]
This paper proposes that the parameter code value 1110 1110 be
used to identify the Timestamp option, and that the syntax and
semantics of Timestamp be identical to that defined in IP.
The Timestamp Option is defined in RFC 791. It is proposed that
the parameter code 1110 1110 be used rather than the option type
code 68 to identify the Timestamp option, and that the parameter
value convey the option length. Octet 1 of the Timestamp
parameter value shall be encoded as the pointer (octet 3 of IP
Timestamp); octet 2 of the parameter value shall be encoded as
the overflow/format octet (octet 4 of IP Timestamp); the
remaining octets shall be used to encode the timestamp list. The
size is fixed by the source, and cannot be changed to accommodate
IETF Page 13
January 6, 1993 CLNP for TUBA Internet Draft
additional timestamp information.
+--------+--------+--------+--------+
|11101110| length | pointer|oflw|flg|
+--------+--------+--------+--------+
| network entity title |
+--------+--------+--------+--------+
| timestamp |
+--------+--------+--------+--------+
| . |
.
5. Error Reporting and Control Message Handling
CLNP and IP differ in the way in which errors are reported to
hosts. In IP environments, the Internet Control Message Protocol
(ICMP, [7]) is used to return (error) messages to hosts that
originate packets that cannot be processed. ICMP messages are
transmitted as user data in IP datagrams. Unreachable
destinations, incorrectly composed IP datagram headers, IP
datagram discards due to congestion, and lifetime/reassembly time
exceeded are reported; the complete internet header that caused
the error plus 8 octets of the segment contained in that IP
datagram are returned to the sender as part of the ICMP error
message. For certain errors, e.g., incorrectly composed IP
datagram headers, the specific octet which caused the problem is
identified.
In CLNP environments, an unique message type, the Error Report
type, is used in the network layer protocol header to distinguish
Error Reports from CLNP datagrams. CLNP Error Reports are
generated on detection of the same types of errors as with ICMP.
Like ICMP error messages, the complete CLNP header that caused
the error is returned to the sender in the data portion of the
Error Report. Implementations should return at least 8 octets of
the datagram contained in the CLNP datagram to the sender of the
original CLNP datagram. Here too, for certain errors, the
specific octet which caused the problem is identified
A summary of the contents of the CLNP Error Report, as it is
proposed for use in TUBA environments, is illustrated in Figure
5-1:
IETF Page 14
Internet Draft CLNP for TUBA January 6, 1993
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........Data Link Header........ | NLP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Header Length | Version | Lifetime (TTL)| 000 | Type=ER |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOTAL Length of Error Report | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest Addr Len | Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PROTO field | Src Addr Len | Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address | Reason for Discard (type/len) |
| | 1100 0001 | 0000 0010 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason for Discard | Options... |
| code | pointer | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that each tick mark represents one bit position.
Figure 5-1. Error Report Format
5.1 Rules for processing an Error Report
The following is a summary of the rules for processing an Error
Report:
IETF Page 15
January 6, 1993 CLNP for TUBA Internet Draft
o+ An Error Report is not generated to report a problem
encountered while processing an Error Report.
o+ Error Reports may not be fragmented (hence, the
fragmentation part is absent).
o+ The Reason for Discard Code field is populated with one of
the values from Table 5-1.
o+ The Pointer field is populated with number of the first
octet of the field that caused the Error Report to be
generated. If it is not possible to identify the offending
octet, this field must be zeroed.
o+ If the Priority or Type of Service option is present in the
errored datagram, the Error Report shall specify the same
option, using the value specified in the original datagram.
o+ If the Security option is present in the errored datagram,
the Error Report shall specify the same option, using the
value specified in the original datagram; if the Security
option is not supported, no Error Report is to be generated.
o+ If the Complete Source Route option is specified in the
errored datagram, the Error Report must compose a reverse of
that route, and return the datagram along the same path.
5.2 Comparison of ICMP and CLNP Error Messages
Table 5-1 provides a loose comparison of ICMP message types and
codes to CLNP Error Type Codes (values in Internet ASCII):
IETF Page 16
Internet Draft CLNP for TUBA January 6, 1993
CLNP Error Type Codes | ICMP Message (Type, Code)
----------------------------------|------------------------------------
Reason not specified (0) | Parameter Problem (12, 0)
Protocol Procedure Error (1) | Parameter Problem (12, 0)
Incorrect Checksum (2) | Parameter Problem (12, 0)
PDU Discarded--Congestion (3) | Source Quench (4, 0)
Header Syntax Error (4) | Parameter problem (12, 0)
Need to Fragment could not (5) | Frag needed, DF set (3, 4)
Incomplete PDU received (6) | Parameter Problem (12, 0)
Duplicate Option (7) | Parameter Problem (12, 0)
Destination Unreachable (128) | Network Unreachable (3, 0)
Destination Unknown (129) | Host Unreachable (3, 1)
Source Routing Error (144) | Source Route failed (3, 5)
Source Route Syntax Error (145) | Source Route failed (3, 5)
Unknown Address in Src Route(146) | Source Route failed (3, 5)
Path not acceptable (147) | Source Route failed (3, 5)
Lifetime expired (160) | TTL exceeded (11, 0)
Reassembly Lifetime Expired (161) | Reassembly time exceeded (11, 1)
Unsupported Option (176) | Parameter Problem (12, 0)
Unsupported Protocol Version(177) | Parameter problem (12, 0)
Unsupported Security Option (178) | Parameter problem (12, 0)
Unsupported Src Rte Option (179) | Parameter problem (12, 0)
Unsupported Rcrd Rte (180) | Parameter problem (12, 0)
Reassembly interference (192) | Reassembly time exceeded (11,1)
Table 5-1. Comparison of CLNP Error Reports to ICMP Error Messages
Note 1: The current use of the source quench is only
when packets are discarded, and thus the current use
meaning is the same; if a future RFC describes a more
robust treatment of the source quench, the applicability
of this CLNP Error Report Type should be reconsidered.
Note 2: There are no corresponding CLNP Error Report Codes for the
following ICMP error message types:
- Protocol Unreachable (3, 2)
- Port Unreachable (3, 3)
[ED. There are error code points available in the ER type
code block that can be used to identify these message types.]
6. Pseudo-Header Considerations
A checksum is computed on UDP and TCP segments to verify the
integrity of the UDP/TCP segment. To further verify that the
UDP/TCP segment has arrived at its correct destination, a
pseudo-header consisting of information used in the delivery of
the UDP/TCP segment is composed and included in the checksum
computation.
IETF Page 17
January 6, 1993 CLNP for TUBA Internet Draft
To compute the checksum on a UDP or TCP segment prior to
transmission, implementations must compose a pseudo-header to the
UDP/TCP segment consisting of the following information that will
be used when composing the CLNP datagram:
o+ Destination Address Length Indicator
o+ Destination Address and PROTO
o+ Source Address Length Indicator
o+ Source Address and Reserved
The total length of the UDP/TCP segment is also included in the
checksum computation. Figure 5-1 illustrates the resulting
pseudo-header when both source and destination addresses are
maximum length.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest Addr Len | Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PROTO field | Src Addr Len | Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address | UDP/TCP segment length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5-1. Pseudo-header
If needed, an octet of zero is added to the end of the UDP/TCP
segment to pad the datagram to a length that is a multiple of 16
bits. In all other respects, rules for computing the checksum are
consistent with RFC 793 and RFC 768.
IETF Page 18
Internet Draft CLNP for TUBA January 6, 1993
7. REFERENCES
IETF Page 19
January 6, 1993 CLNP for TUBA Internet Draft
[1] ISO 8473--International Standards Organization--Data
Communications-- Protocol for Providing the
Connectionless-mode Network Service
[2] Callon, R., TCP/UDP over Bigger Addresses (TUBA), Request for
Comments 1347, Network Information Center, SRI
International, Menlo Park, CA, May 1992.
[3] Postel, J., Transmission Control Protocol (TCP). Request for
Comments 793, Network Information Center, SRI
International, Menlo Park, CA, 1981 September.
[4] Postel, J., User Datagram Protocol (UDP). Request for Comments 768,
Network Information Center, SRI International, Menlo Park, CA.
[5] Postel, J., Internet Protocol (IP). Request for Comments 791,
Network Information Center, SRI International, Menlo Park,
CA, 1981 September.
[6] Chapin, L., ISO CLNP, Draft International Standard version,
Request for Comments 994, Network Information Center, SRI
International, Menlo Park, CA.
[7] ISO 8348--International Standards Organization--Data
Communications--OSI Network Layer Addressing
[8] Callon, R., Addressing for the new Internet.
Request for Comments iiii, Network Information Center, SRI
International, Menlo Park, CA.
[9] Reynolds, J., and J. Postel, Assigned Numbers.
Request for Comments 1340, Network Information Center, SRI
International, Menlo Park, CA.
[10] Kent, S., Security Option for IP,
Request for Comments 1108, Network Information Center, SRI
International, Menlo Park, CA.
[11] Almquist, P., Type of Service in the Internet
Protocol Suite. Request for Comments 1349, Network Information
Center, SRI International, Menlo Park, CA.
[12] ISO 6523 -- International Code Designators
[13] Callon, R., NSAPA Guidelines for the Internet,
Request for Comments RFC 1237, Network Information Center, SRI
International, Menlo Park, CA.
[14] Hagens, R. and C. Wittbrodt, CLNP Ping, Request for Comments
1139, Network Information Center, SRI
International, Menlo Park, CA.
IETF Page 20
Internet Draft CLNP for TUBA January 6, 1993
Appendix A. Checksum Algorithms (from ISO 8473)
Symbols used in algorithms:
c0, c1 variables used in the algorithms
i position of octet in header (first
octet is i=1)
Bi value of octet i in the header
n position of first octet of checksum (n=8)
L Length of header in octets
X Value of octet one of the checksum parameter
Y Value of octet two of the checksum parameter
Addition is performed in one of the two following modes:
o+ modulo 255 arithmetic;
o+ eight-bit one's complement arithmetic;
The algorithm for Generating the Checksum Parameter Value is as
follows:
A. Construct the complete header with the value of the
checksum parameter field set to zero; i.e., c0 <- c1 <- 0;
B. Process each octet of the header sequentially from i=1 to L
by:
o+ c0 <- c0 + Bi
o+ c1 <- c1 + c0
C. Calculate X, Y as follows:
o+ X <- (L - 8)(c0 - c1) modulo 255
o+ Y <- (L - 7)(-C0) + c1
D. If X = 0, then X <- 255
E. If Y = 0, then Y <- 255
F. place the values of X and Y in octets 8 and 9 of the
header, respectively
The algorithm for checking the value of the checksum parameter is
as follows:
A. If octets 8 and 9 of the header both contain zero, then the
checksum calculation has succeeded; else if either but not
both of these octets contains the value zero then the
checksum is incorrect; otherwise, initialize: c0 <- c1 <- 0
IETF Page 21
January 6, 1993 CLNP for TUBA Internet Draft
B. Process each octet of the header sequentially from i = 1 to
L by:
o+ c0 <- c0 + Bi
o+ c1 <- c1 + c0
C. When all the octets have been processed, if c0 = c1 = 0,
then the checksum calculation has succeeded, else it has
failed.
There is a separate algorithm to adjust the checksum parameter
value when a octet has been modified (such as the TTL). Suppose
the value in octet k is changed by Z = newvalue - oldvalue. If X
and Y denote the checksum values held in octets n and n+1
respectively, then adjust X and Y as follows:
If X = 0 and Y = 0 then do nothing, else if X = 0 or Y = 0 then
the checksum is incorrect, else:
X <- (k - n - 1)Z + X modulo 255
Y <- (n - k)Z + Y modulo 255
If X = 0, then X <- 255; if Y = 0, then Y <- 255.
In the example, n = 89; if the octet altered is the TTL (octet
4), then k = 4. For the case where the lifetime is decreased by
one unit (Z = -1), the assignment statements for the new values
of X and Y in the immediately preceeding algorithm simplify to:
X <- X + 5 Modulo 255
Y <- Y - 4 Modulo 255